Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000008_owner-urn-ietf _Sun Nov 3 09:50:09 1996.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA17886 for urn-ietf-out; Sun, 3 Nov 1996 09:50:09 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA17881 for <[e-mail]>; Sun, 3 Nov 1996 09:50:07 -0500
Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA17382  (mail destined for [e-mail]); Sun, 3 Nov 96 09:50:04 -0500
Received: from nic.cafax.se ([e-mail] [193.12.122.42])
        by nic.cafax.se (8.8.2/8.8.2) with SMTP
        id PAA00892;
        Sun, 3 Nov 1996 15:49:51 +0100 (MET)
Date: Sun, 3 Nov 1996 15:49:50 +0100 (MET)
From: Patrik Faltstrom <[e-mail]>
X-Sender: [e-mail]
To: Daniel LaLiberte <[e-mail]>
Cc: Terry Allen <[e-mail]>, [e-mail]
Subject: Re: Names and Locations (was [URN] some comments)
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: Patrik Faltstrom <[e-mail]>
Errors-To: [e-mail]

On Sun, 3 Nov 1996, Daniel LaLiberte wrote:

> and perhaps it is irrelevant semantics.  What is relevant is that you
> guys make a distinction between URLs and URNs, and it is a
> distinction founded on a misunderstanding.  I've been trying to dig
> through to get to the heart of that misunderstanding.

This is not a misunderstanding at all. There _is_ a difference between
a URN and a URL which from my point of view _you_ have not understood.

A URL refers to a location which though a caching mechanism, a proxy
cache, an interceptor with cache, multiple A-records in DNS or whatever
ends up refering to more than one occurance of the same resource.

A URN is a _name_ of a resource which have absolutely _NOTHING_
to do with the resolution protocol, the different versions of
the resource that exist (text, postscript etc), the different
protocols used to locate and later fetch the resource or the
metadata for the resource.

There are a couple of us that during all of the years so far has
only been talking about this difference being very very important.

If you don't understand this difference...well...what are _we_
supposed to do about that. The difference is needed!

> But the very same URL was used to retrieve the resource either from a
> cache or from a remote server.  So what "location" is the URL
> identifying when the resource actually lives in multiple places - the
> very same URL may be used to fetch the resource from any of those
> places?  Notice you first say that a URL identifies (or names) the
> location of a resource, and then we find out that there are really
> multiple locations identified by the URL.  But that is supposed to be
> the job of URNs.  So why do we need URNs?

Please Dan! There is a difference between having two A-records
pointing to two different IP-addresses, and when you later connect
to that hostname (which is resolved to one of the two addresses)
you will end up at one of the two locations. You can use this technique
in for example the hostname in a URL of course. You can also
use a proxy cache or an interceptor to see that you pick the
copy of the resource that is the most convinient for you.

BUT, you are still refering to _one_ location where the resource
is located. If you happen to have a local copy, well, let's use that one.
It's the same thing as if you do an lseek() in the filesystem and
want to read some bytes from a file. If the filesystem have cached those
diskblocks, and give you the copies of the bits that happened to
sit in RAM and not on the physical disk, are you not using an
lseek() anyway?

Dan, you _have_ to start to differ between multiple locations
of a resource which is addressed by a URL - i.e. it's original
location, and the functionality that is built into the system
when a _name_ is assigned to a resource. As long as you have not
seen this difference that many of us others have seen, it is
a little bit hard to have a meaningful discussion.

Sorry for being harsh and short, but I am now a little bit tired
of having to try to come up with exactly the same arguments we
have been having since the UR* discussions started. We have
to move forward!

> I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for
> either.  (BTW, If "urn:" is optional, then
> "urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it
> is an equivalent identifier).  A client can resolve
> "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or
> something else.  This is the very same identifier, not two identifiers
> with the same character representation.  Calling it two identifiers
> and saying one is a name and the other is [the name of] a location is
> missing the whole point.

No, _you_ are missing the point. By saying that
"urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this
namespace called HTTP can grandfather other namespaces, this
_name_ can stay as it is even if the resource moves, the metadata
for this resource can be fetched etc etc all according to the URN
spec that was written down years ago.

If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do
if you have to move this resource from the host www.ncsa.uiuc.edu?
Change things in the DNS? But of course that works. But, if you move
the information from staying only on an http server to also stay in
a Z39.50 database and want the clients to be able to use both, or
if the resolution from www.ncsa.uiuc.edu to a hostname, which later
is turned into an IP-address in DNS is not done in DNS for some reason
in the future? What if the resource is mirrored to a different site?

There are thousands of things you _can_not_do_ with the name of a
location of something, that you only can do with a _name_ of a
resource which is resolved to one or many alternative locations.

> The point is a single identifier can, in fact, be resolved many
> different ways by clients.  Some ways are more direct (e.g. HTTP) and
> some are more indirect (e.g. NAPTR).  They are all resolution
> mechanisms.  They all result, eventually, in the resource, or whatever
> is being requested.

You _have_ to start to look at what kind of resolutions you do,
and can do. Just because you can have one A-record point to a list
of IP-addresses, that doesn't help you because the way the zones
in DNS are delegated. You _have_ to look at who owns what part
of the information used in the resolution process!

> I see no difference between *names* and *locations* at least
> regarding the identifiers themselves.

I can see that. There seems to, though, to be a number of people
that do, and I am one of them.

   Patrik